Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-133.txt

Text File | 1994-12-08 | 40.8 KB | 1,120 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 06 Jul 92       Volume 1 : Issue 133

Today's Topics:

    Most efficient way to load a patten in a LDEF
    Making my own TMPLs in ResEdit
    Learning OOP
    How do I make color icon show up in Finder?
    Things I'd like to see in THINK C
    ETO 7 and MacApp



-------------------------------------------------------

From: [e-mail] (Matt Mora)
Subject: Most efficient way to load a patten in a LDEF
Date: 27 May 92 18:20:05 GMT
Organization: SRI International, Menlo Park, California



I am writing a custom ldef in pascal (I know this seems to be the major
source of my problem) and I want to draw a gray line. The problem is
that I have no access to QD globals. I could do some funky thing like store
a5 and so forth. But what I'm doing now is stuffing the gray data into a
pattern variable one byte at a time. Being that this is in the draw
portion of the ldef I don't want to be wasting a lot of time just moving the
pattern data around. I was wondering if someone out there knows of an
efficient way to do this?

What my code breaks down to is

MOVE.B  #$AA,-$0148(A6)
MOVE.B  #$55,-$0147(A6)
MOVE.B  #$AA,-$0146(A6)
MOVE.B  #$55,-$0145(A6)
MOVE.B  #$AA,-$0144(A6)
MOVE.B  #$55,-$0143(A6)
MOVE.B  #$AA,-$0142(A6)
MOVE.B  #$55,-$0141(A6)

Which looks terribly inefficient.

What I would like is a better way to do this maybe a pascal inline that moves
the data long words at a time. There must be a better way. Any clues?



Thanks

Matt







- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 27 May 92 21:33:54 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>I am writing a custom ldef in pascal (I know this seems to be the major
>source of my problem) and I want to draw a gray line. The problem is
>that I have no access to QD globals. I could do some funky thing like store
>a5 and so forth. But what I'm doing now is stuffing the gray data into a
>pattern variable one byte at a time. Being that this is in the draw
>portion of the ldef I don't want to be wasting a lot of time just moving the
>pattern data around. I was wondering if someone out there knows of an
>efficient way to do this?

Since you know that the LDEF will be called from an application, which by
definition has a valid "A5 world", you should just grab the pattern from the
Quickdraw globals.  Here's some Pascal code I use to get a pointer to these
globals.

In your situation, you'd write something like PenPat(GetGrafGlobals^.gray);

Restrictions: 1) The globals record should be treated as strictly read-only.
2) The inline function should only be called under circumstances where you're
certain there's a valid A5-world.

 TYPE
  GrafGlobalsPtr = ^GrafGlobals;

{ the Quickdraw global variables }
{ as defined in the MPW assembler Quickdraw header file }
  GrafGlobals = RECORD
{ private }
    fontData: array[1..22] of SignedByte;
    playIndex: longint;
    fontPtr: FMOutPtr;
    fontAdj: Fixed;
    patAlign: Point;
    polyMax: integer;
    thePoly: PolyHandle;
    qdSpare0: integer;
    playPic: longint;
    rgnMax: integer;
    rgnIndex: integer;
    rgnBuf: handle;
    wideData: Region;
    wideMaster: RgnPtr;
    wideOpen: RgnHandle;
{ public }
    randSeed: longint;
    screenBits: BitMap;
    arrow: Cursor;
    dkGray: Pattern;
    ltGray: Pattern;
    gray: Pattern;
    black: Pattern;
    white: Pattern;
    thePort: GrafPtr;
   END; { GrafGlobals = RECORD }

 FUNCTION GetGrafGlobals: GrafGlobalsPtr;
 INLINE
  $2055,        { move.l (A5), A0 }
  $41E8, $FF36,        { lea fontData(A0), A0 }
  $2E88;        { move.l A0, (SP) }


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 28 May 92 14:50:37 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Matt Mora) writes:

> I am writing a custom ldef in pascal (I know this seems to be the major
> source of my problem) and I want to draw a gray line.

If you persist in slurring Pascal in this way, I shall be forced to ask
you to step outside. :-)

Seriously, LDEFs are easy to write. The main pitfall is that, in the
argument list on page IV-276, the "lRect" argument should have a "var"
in front of it.

> The problem is that I have no access to QD globals.

Actually, you do (after all, QuickDraw can access them, can't it?).
The trick is that you have to do the accesses the same way QuickDraw
itself does: by double-indirecting from A5.

When an application calls InitGraf(@thePort), QuickDraw assumes that A5
points to a longword in memory that it can use to save a pointer to its globals.
It sets up this longword as follows:

    A5 ----> QD global ptr ----> thePort

For the particular case of the standard 50% grey pattern, here's a routine
which will return a PatPtr that you can dereference and pass to the
appropriate QuickDraw calls:

    Function grayPtr : PatPtr;

        Inline
        $2055,        { move.l (a5), a0 }
        $41E8, $FFE8,    { lea -24(a0), a0 }
        $2E88;        { move.l a0, (sp) }

It's easy enough to create corresponding routines for the other globals.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Any opinions the author has expressed in this posting are sacred to
Epimetheus, the Greek god of hindsight.

+++++++++++++++++++++++++++

From: [e-mail] (John Wallace)
Organization: TRW Data Systems Center, Redondo Beach, CA
Date: Thu, 28 May 92 21:30:49 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>
>
>I am writing a custom ldef in pascal (I know this seems to be the major
>source of my problem) and I want to draw a gray line. The problem is
>that I have no access to QD globals. I could do some funky thing like store
>a5 and so forth. But what I'm doing now is stuffing the gray data into a
>pattern variable one byte at a time. Being that this is in the draw
>portion of the ldef I don't want to be wasting a lot of time just moving the
>pattern data around. I was wondering if someone out there knows of an
>efficient way to do this?
>
>What my code breaks down to is
>
>MOVE.B  #$AA,-$0148(A6)
>MOVE.B  #$55,-$0147(A6)
>MOVE.B  #$AA,-$0146(A6)
>MOVE.B  #$55,-$0145(A6)
>MOVE.B  #$AA,-$0144(A6)
>MOVE.B  #$55,-$0143(A6)
>MOVE.B  #$AA,-$0142(A6)
>MOVE.B  #$55,-$0141(A6)
>
>Which looks terribly inefficient.
>
>What I would like is a better way to do this maybe a pascal inline that moves
>the data long words at a time. There must be a better way. Any clues?
>
>
>Thanks
>
>Matt
>___________________________________________________________
>Matthew Mora                |   my Mac  [e-mail]
>SRI International           |  my unix  [e-mail]
>___________________________________________________________


I've got some code that gives you access to the QuickDraw globals.
I use this a lot in INITs or other code resources where I don't
have an A5 environment of my own, but need access to these
values.  I base everything off of the low-memory global
CurrentA5 since I don't know if A5 is necessarily valid when
my code may be called.

It goes something like this:


type
  QDPtr = ^QDRecord;
  QDRecord = record
    randSeed : LongInt;
    screenBits : BitMap;
    arrow : Cursor;
    dkGray : Pattern;
    ltGray : Pattern;
    gray : Pattern;
    black : Pattern;
    white : Pattern;
    thePort : GrafPtr;
  end;


const
  QDRecordSize = SizeOf(QDRecord);
  QDRecordOffset = -QDRecordSize + SizeOf(GrafPtr);


function GetQDGlobals : QDPtr;
inline
  $2078, $0904, (* move.l  CurrentA5,a0 ; get the value of a5 *)
  $2050,        (* move.l (a0),a0       ; point to thePort in QD globals *)
  $41E8, QDRecordOffset,
                (* lea.l QDRecordOffset(a0),a0  ; add QDRO to a0 *)
  $2E88;        (* move.l a0,(a7)       ; return pointer to QD globals *)


function thePort : GrafPtr;
begin
  thePort := GetQDGlobals^.thePort;
end;


function white : Pattern;
begin
  white := GetQDGlobals^.white;
end;

etc. etc. etc.



Hope this helps!
John

- ----
John Wallace    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 1 Jun 92 14:43:26 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (John Wallace) writes:

> I've got some code that gives you access to the QuickDraw globals.
> I use this a lot in INITs or other code resources where I don't
> have an A5 environment of my own, but need access to these
> values.  I base everything off of the low-memory global
> CurrentA5 since I don't know if A5 is necessarily valid when
> my code may be called.

But how do you know that InitGraf has been called for the A5 world in
CurrentA5?

+++++++++++++++++++++++++++

From: [e-mail]
Date: 1 Jun 92 06:23:08 GMT

In article <[e-mail]> [e-mail]
(JohnC) writes:
> In article <[e-mail]> [e-mail] (Matt Mora) writes:
> >I am writing a custom ldef in pascal (I know this seems to be the major
> >source of my problem) and I want to draw a gray line. The problem is
> >that I have no access to QD globals. I could do some funky thing like store
> >a5 and so forth. But what I'm doing now is stuffing the gray data into a
> >pattern variable one byte at a time. Being that this is in the draw
> >portion of the ldef I don't want to be wasting a lot of time just moving the
> >pattern data around. I was wondering if someone out there knows of an
> >efficient way to do this?
>
> Since you know that the LDEF will be called from an application, which by
> definition has a valid "A5 world", you should just grab the pattern from the
> Quickdraw globals.  Here's some Pascal code I use to get a pointer to these
> globals.

It did not appear in the original post that the LDEF was being called from an
application, so it wouldn't be kosher to assume as such. Besides, the thought
police would come after you if you wrote an *DEF that was restricted to ONLY
applications, and useless in DA's, XCMD's, cdev's, PhotoShop Plug-ins, Quark
XTensions. (you get the point.)

I often like to tack a pointer to some useful information in a data structure's
reference constant, namely myList^^.refcon.  You can stuff a pointer to a
pattern, or a pointer to a structure that contains a pattern. Either way that's
only one dereference away.(plus or minus a bit)

But what I do most often is not even compile an LDEF completely, but rather
have a six-byte 'LDEF stub' resource whose first two bytes are the JMP
instruction, and the last four bytes are a pointer back into my code. This way
the 'LDEF proc' has access to all globals & goodies. Likewise, I don't have to
stuff the data into the ListHandle, I just use the cell.h & cell.v (handed to
me in the LDEF drawing proc) to index into my own data.

LDEF's tend to be much more data-specific than do CDEF's or WDEF's, so they
lend themselves nicely to this 'embedded' calling sequence.

- --
Roy Lovejoy      | internet:  [e-mail]
Coding Juggler   | AppleLink: adept
Adept Solutions  | CIS:       72447,1447
.................| dual certified developer: NeXT & Apple ;)

+++++++++++++++++++++++++++

From: [e-mail] (Herb Poppe)
Organization: Scientific Computing Division/NCAR Boulder, CO
Date: Fri, 5 Jun 1992 14:45:12 GMT

In article <[e-mail]> [e-mail]
writes:

> But what I do most often is not even compile an LDEF completely, but
rather
> have a six-byte 'LDEF stub' resource whose first two bytes are the JMP
> instruction, and the last four bytes are a pointer back into my code.
This way
> the 'LDEF proc' has access to all globals & goodies.

It also makes it possible to debug the LDEF using the symbolic debugger of
THINK C or Pascal, say. I would appreciate seeing the code you use for
your LDEF stub, and the code you use to modify the last four bytes to
point to the actual LDEF code within the application, a discussion of any
gotchas related to segments, etc.

Thanks.

Herb Poppe                 National Center for Atmospheric Research (NCAR)
[e-mail]       1850 Table Mesa Dr.
[phone]             Boulder, CO  80303

---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: Making my own TMPLs in ResEdit
Date: 3 Jun 92 14:38:29 GMT
Organization: U of Wisconsin-Madison College of Engineering

First of all, many thanks and cookies to those who responded to my question on
launching, especially Marty(?) Grobbins, Larry Rosenstein, and Pete Resnick.
I think I've got that pretty well under control now.

My question this time is, where can I get info on making my own TMPLs in
ResEdit?  I've played around a little, using the STR# TMPL as an example, and
I've been able to get a working TMPL of my own that serves the purpose.
Obviously, though, there's a lot more there to work with, and I'd like to
find out what it is.  Also, as far as I've been able to tell, the TMPL has to
reside in the ResEdit application's resource fork for it to work.  Just putting
it in the resource file where I'm using it doesn't seem to do it for ResEdit.
This would imply that if I move to a different machine, with its own copy of
ResEdit, I would have to carry along a copy of the TMPL, make a copy of
ResEdit, use the copy of ResEdit to edit the original and paste in the TMPL,
etc.  Is this in fact the case?


Thanks,
Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 3 Jun 1992 16:39:03 GMT

[e-mail] (Jeffrey Verdegan) writes:
>
>My question this time is, where can I get info on making my own TMPLs in
>ResEdit?

The only place I've seen them documented is in the ResEdit manual, which
is $14.95 from APDA (ask for M0015LL/D).  Unfortunately, since ResEdit's
interface is so darn good, that's about the only thing you'll need the
manual for, and it's hard to justify fifteen bucks for about two and a
half pages.

Are there any legality problems with typing in about 2K worth of How To
Do TMPLs In ResEdit?  I'd do it...

>Also, as far as I've been able to tell, the TMPL has to
>reside in the ResEdit application's resource fork for it to work.  Just putting
>it in the resource file where I'm using it doesn't seem to do it for ResEdit.

Actually, it does.  I think you have to save the file first, though.
And, if you want a TMPL that works with any file, put it in the ResEdit
Preferences file, not the ResEdit application itself.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "I've got the trash, and you've got the cash / baby we should get along fine
  Gimme all your money, coz I know you think I'm funny
  Can't you see me laugh?  Can't you see me smiling?"  - Joe Jackson

+++++++++++++++++++++++++++

From: [e-mail] (Dave Martin)
Date: 3 Jun 1992 21:59:00 GMT
Organization: Geochemical & Environmental Research Group, Texas A&M University

In article <[e-mail]>, [e-mail] (Jeffrey Verdegan) writes...
>Also, as far as I've been able to tell, the TMPL has to
>reside in the ResEdit application's resource fork for it to work.  Just putting
>it in the resource file where I'm using it doesn't seem to do it for ResEdit.
>This would imply that if I move to a different machine, with its own copy of
>ResEdit, I would have to carry along a copy of the TMPL, make a copy of
>ResEdit, use the copy of ResEdit to edit the original and paste in the TMPL,
>etc.  Is this in fact the case?

As long as the TMPL is in a file opened in ResEdit, it should work. I've
had no problems with having a TMPL only in the file with the resource that
the TMPL was created for. I can't recall if I've tried with it in a file
other than the one with the resource to be edited, though.
A good source of info on ResEdit TMPL's would be the book ResEdit Complete
(I believe that's the title), which comes with ResEdit 2.0 (old version,
but good book). I believe that I may also have at home a DA which I
downloaded from America Online which has all the TMPL field info within
it for easy lookup. I'll try to remember to find it tonight and either post
it on SUMEX or (if you drop me a line) mail it out to you.

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 4 Jun 92 06:20:29 GMT
Organization: Personal

In article <[e-mail]>, [e-mail] (Jeffrey Verdegan) writes:

> My question this time is, where can I get info on making my own TMPLs in
> ResEdit?

Be carefull here, TMPL subtypes were expanded, and the new ResEdit manual has
the full scoop.  The 2 new subtypes are 'P0xx' and 'Cxxx' which give padded
string fields of length (hex) xx +1 and xxx +1, constructed as pascal or C
strings (0 padded). (yes, that is a zero following the P).  These are analogues
to the 'Hxxx' subtype.

> Also, as far as I've been able to tell, the TMPL has to
> reside in the ResEdit application's resource fork for it to work.

not so, you have to save any freshly created resource for ResEdit to use it.
Once saved, it will be available if its file is open.  I have a small machine,
and have found i necessary to minimize the application heap (remember, the
TMPL is only needed by ResEdit) so I abstract the TMPLs to file(s) which I
add to the Open Special menu for fast access.

Incidentally, ResEdit can be fussy with large, complex TMPLs. (an argument
for MPW Rez)  Expect to crash, and save often.  It seems to help if you work
from the end first.

Good luck, DSE.

---------------------------

From: [e-mail] (Wade Williams)
Subject: Learning OOP
Organization: Auburn University
Date: Thu, 4 Jun 1992 13:52:20 GMT

Ok, I'm a Macintosh programmer.  Maybe not a good one, but I have a good
understanding of Pascal and C and using the Toolbox.

Now, I'd like to move to the object-oriented world.  However, I've never found
a single good book on Object-oriented programming for the Macintosh using THINK
C, C++ or anything else.  The one book I've seen "Object oriented programming
for the Macintosh" or something like that, is way out of date and just
basically describes OOP in about 3 different languages.

We're told how wonderful MacApp is, how wonderful C++ is and how wonderful the
THINK Class Library is.  However, those who don't know OOP already are out of
luck - the materials that come with such environments are focused at those who
already know OOP, or at least are much to brief for beginners.

I know there are books such as "Programming with MacApp," but you really need
to learn the OOP concepts and do some basic OOP before diving into MacApp.

So, my question is:  Are there any learning materials that I have missed?  I
know about the Developer University course, but I don't have the $795 for the
course and MPW C++.  Where can we turn to learn this wonderful programming
model?

- -------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
- -------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 4 Jun 92 16:23:26 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Wade Williams) wrote:
>
> So, my question is:  Are there any learning materials that I have missed?  I

You might look at "Object Oriented Design with Applications" by Grady Booch.
The first part of the book talks about OO design in general, and the "Booch
notation".  The last section discusses several different OOP
languages/environments, including MacApp/Object Pascal, C++, Smalltalk, ...

- ----
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (allen Adams)
Organization: TRW Inc., Redondo Beach, CA
Date: Thu, 4 Jun 92 18:41:50 GMT

[e-mail] (Larry Rosenstein) writes:

>In article <[e-mail]>, [e-mail]
>(Wade Williams) wrote:
>>
>> So, my question is:  Are there any learning materials that I have missed?  I

>You might look at "Object Oriented Design with Applications" by Grady Booch.
>The first part of the book talks about OO design in general, and the "Booch
>notation".  The last section discusses several different OOP
>languages/environments, including MacApp/Object Pascal, C++, Smalltalk, ...

I read the first 2/3 of the book, which dealt with OOD, which I enjoyed.
But for some reason, the Application section 'took the wind out of my sails',
and I have yet to complete it.  Were the examples to 'dry', complicated,
non-interesting, etc. to anyone else??  Or maybe I need to see if 'the wind
has picked up' and try again.

Allen Adams


---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: How do I make color icon show up in Finder?
Date: 28 May 92 21:30:47 GMT
Organization: U of Wisconsin-Madison College of Engineering

I've recently written an INIT/extension.  I've got a cute little icon with it.
I also made cicns. I've put all the appropriate stuff in the BNDL, and when
I look at the thing on the desktop, it has my icon, but it's 1-bit black and
white.  I set the thing up as per Mark & Reed's THINK C Primer, adding in cicns
where it seemed "intuitively" appropriate.  Is there something else one has to
do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
RTFM if someone can tell me which FM to R.

Thanks much!
Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 29 May 92 02:31:35 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Jeffrey Verdegan) writes:
>
> I've recently written an INIT/extension.  I've got a cute little icon with it.
> I also made cicns. I've put all the appropriate stuff in the BNDL, and when
> I look at the thing on the desktop, it has my icon, but it's 1-bit black and
> white.  I set the thing up as per Mark & Reed's THINK C Primer, adding in
cicns
> where it seemed "intuitively" appropriate.  Is there something else one has to
> do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
> RTFM if someone can tell me which FM to R.

If Mark & Reed are telling you to use cicn's, the you're R'ing the wrong FM. One
FM that you could R is Inside Mac VI, Chapter 9. The easiest way to get color
icons into your application is to simply use ResEdit 2.1.1. Its BNDL and icon
editors make it all so simple.

If you don't have the latest ResEdit, you can ftp it from ftp.apple.com,
/dts/mac/tools/resedit.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 29 May 92 20:51:36 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>
> In article <[e-mail]>, [e-mail]
> (Jeffrey Verdegan) writes:
> >
> > I've recently written an INIT/extension.  I've got a cute little icon with it.
> > I also made cicns. I've put all the appropriate stuff in the BNDL, and when
> > I look at the thing on the desktop, it has my icon, but it's 1-bit black and
> > white.  I set the thing up as per Mark & Reed's THINK C Primer, adding in
> cicns
> > where it seemed "intuitively" appropriate.  Is there something else one has to
> > do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
> > RTFM if someone can tell me which FM to R.
>
> If Mark & Reed are telling you to use cicn's, the you're R'ing the wrong FM. One
> FM that you could R is Inside Mac VI, Chapter 9. The easiest way to get color
> icons into your application is to simply use ResEdit 2.1.1. Its BNDL and icon
> editors make it all so simple.
>
> If you don't have the latest ResEdit, you can ftp it from ftp.apple.com,
> /dts/mac/tools/resedit.
>
> --
> Keith Rollin
> Phantom Programmer
> Taligent, Inc.

Ooops, Keith.  I suspect you missed the simple solution here.  I think Jeff
just needs to rebuild his desktop.  Hold down the Command & Option keys as
soon as the menu bar appears after rebooting.  Answer yes to the "Are you
sure?" dialog that appears and wait patiently.  This rebuilding updates all
your icons and makes everything all pleasant again.  Do this every couple of
months or whenever you notice goofy icon problems (like blank, b&w, etc).

Jon
on the Apple side of the DA6 Iron Curtain


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jun 92 00:23:57 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
>
>In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>>
>>In article <[e-mail]>, [e-mail]
>> (Jeffrey Verdegan) writes:
>>>
>>> I've recently written an INIT/extension.  I've got a cute little icon with
it.
>>> I also made cicns. I've put all the appropriate stuff in the BNDL, and when
>>> I look at the thing on the desktop, it has my icon, but it's 1-bit black and

>>> white.  I set the thing up as per Mark & Reed's THINK C Primer, adding in
cicns
>>> where it seemed "intuitively" appropriate.  Is there something else one has
to
>>> do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
>>> RTFM if someone can tell me which FM to R.
>>
>> If Mark & Reed are telling you to use cicn's, the you're R'ing the wrong FM.
One
>> FM that you could R is Inside Mac VI, Chapter 9. The easiest way to get color
>> icons into your application is to simply use ResEdit 2.1.1. Its BNDL and icon
>> editors make it all so simple.
>>
>> If you don't have the latest ResEdit, you can ftp it from ftp.apple.com,
>> /dts/mac/tools/resedit.
>
> Ooops, Keith.  I suspect you missed the simple solution here.  I think Jeff
> just needs to rebuild his desktop.  Hold down the Command & Option keys as
> soon as the menu bar appears after rebooting.  Answer yes to the "Are you
> sure?" dialog that appears and wait patiently.  This rebuilding updates all
> your icons and makes everything all pleasant again.  Do this every couple of
> months or whenever you notice goofy icon problems (like blank, b&w, etc).
>
> Jon
> on the Apple side of the DA6 Iron Curtain

Hmmm...I'd hate to argue with someone who has played around with the Finder a
lot, but, as they used to say on Hollywood Squares, "I disagree."

I guess I didn't state what I saw as the real problem. In order to draw color
icons, the Finder uses ics8, ics4, icl8, and icl4 resources. It doesn't use the
cicn resource. An INIT called ColorFinder would allow one you display color
icons under Finder 6.0 by attaching cicn's to your application. However, that is
not a system supported feature (I'm not even sure if it will work under 7.0).

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Jeffrey Verdegan)
Date: 1 Jun 92 21:49:07 GMT
Organization: U of Wisconsin-Madison College of Engineering

In article <[e-mail]> [e-mail] (Jon Pugh) writes:
>In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>>
>> In article <[e-mail]>, [e-mail]
>> (Jeffrey Verdegan) writes:
>> >
>> > I've recently written an INIT/extension.  I've got a cute little icon with it.
[stuff deleted]
>> > where it seemed "intuitively" appropriate.  Is there something else one has to
>> > do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
>> > RTFM if someone can tell me which FM to R.
>>
>> If Mark & Reed are telling you to use cicn's, the you're R'ing the wrong FM. One
>> FM that you could R is Inside Mac VI, Chapter 9. The easiest way to get color
>> icons into your application is to simply use ResEdit 2.1.1. Its BNDL and icon
>> editors make it all so simple.
>
[more stuff deleted]
>Ooops, Keith.  I suspect you missed the simple solution here.  I think Jeff
>just needs to rebuild his desktop.  Hold down the Command & Option keys as
[yet another deletion]

Yep.  It was a classic case of "Forest For The Trees."

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 3 Jun 92 20:58:58 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>
> I guess I didn't state what I saw as the real problem. In order to draw color
> icons, the Finder uses ics8, ics4, icl8, and icl4 resources. It doesn't use the
> cicn resource.

Correct, and re-reading the original post makes this appear to be the case.
However, if this _is_ the case and he adds icl* resources, he _will_ need to
rebuild the desktop too.

I guess we're both right. ;)

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 4 Jun 92 21:34:05 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jeffrey Verdegan) writes:

> I've recently written an INIT/extension.  I've got a cute little icon with it.
> I also made cicns. I've put all the appropriate stuff in the BNDL, and when
> I look at the thing on the desktop, it has my icon, but it's 1-bit black and
> white.  I set the thing up as per Mark & Reed's THINK C Primer, adding in cicns
> where it seemed "intuitively" appropriate.  Is there something else one has to
> do in Sys 7 to get the color icon to show up on the desktop?  I'll happily
> RTFM if someone can tell me which FM to R.

Cicns? Let's us be specific. The resources you need to make are:
ICN#  1bit 32*32 pixel icon
icl4  4bit 32*32 pixel icon
icl8  8bit 32*32 pixel icon
ics#  1bit 16*16 pixel icon
ics4  4bit 16*16 pixel icon
ics8  8bit 16*16 pixel icon

These icons are the ones that are drawn in the Finder. Isn't a cicn a
color ICON?

Jeremiah
     _______________________________
    /___  . _____. ___  __  ___  . /
       / / /____/ /__/ / / /__> / /
__    / / _____/   ___/ / ___  / /
\ \__/ / /____/ /\ \   / /__> / /___
 \____/______/ /  \_\ /______/_____/
[e-mail]

"When the world is running down, you make the best of what's still
around."
                         -Sting

---------------------------

From: [e-mail] (Steven J. Edwards)
Subject: Things I'd like to see in THINK C
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
Date: 29 May 92 15:12:57

Here are a few things I'd like to see considered for inclusion in the
next update to THINK C:

1) Calls to malloc() should return addresses that are four byte
aligned.  Although it doesn't make much difference to 16 bit Macs, the
time speedup is considerable with those with 32 bit bus structure
machines.  I have already made a local fix for this, but I think that
it should really be handled by the library as is the case with the
even byte alignment already in place.

2) Four byte alignment of static/extern and auto items would be nice
and can only be reliably done by the compiler.  Perhaps this could be
selected by the preference menu.

3) Flagging of undefined preprocessor symbols when tested by "#if"
would be nice.  Perhaps this is required by the standard; I thought
that any reference to an undefined preprocessor symbol would cause a
diagnostic unless it was a #define, #ifdef, #ifndef, or defined()
operator.

4) Have the project file remember the target location of the link
output between invocations of THINK C.  Right now the location is only
remembered for the duration of a single THINK C invocation.  Also, it
should be able to proceed directly to and through the link phase
without manual attention if so specified by a preference selection.

5) Minor text policing as is already done by some editors.  This
includes detection and optional elimination of bogus characters,
trailing or superflous blanks, trailing or superflous tabs, embedded
NULs, and initial or trailing empty lines.

6) A global, multifile "replace all" command to change text.
Currently, this operation requires a series of command-T and menu
picks for each file involved.  It gets kind of annoying if there are
tens to hundreds of files in the project.

7) An extra button on global replacement file list dialog that checks
all files except system include files (those referenced with <>
instead of "").

 [The above opinions expressed are my own; not necessarily held by others.]
      == Steven J. Edwards           Bull HN Information Systems Inc. ==
      == [phone]              300 Concord Road         MS 820A ==
      == [e-mail]     Billerica, MA 01821          USA ==
"That Government which Governs the Least, Governs Best." -- Thomas Jefferson

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 30 May 92 12:15:48 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Steven J. Edwards) writes:

   Here are a few things I'd like to see considered for inclusion in the
   next update to THINK C:

We all have those, right ?

   1) Calls to malloc() should return addresses that are four byte
   aligned.  Although it doesn't make much difference to 16 bit Macs, the

   2) Four byte alignment of static/extern and auto items would be nice

Uh... aren't these taken care of if you use 4-byte ints (and the
respective libraries, of course) ?

   6) A global, multifile "replace all" command to change text.

Mmh.

   7) An extra button on global replacement file list dialog that checks
   all files except system include files (those referenced with <>
   instead of "").

Yes ! Yes ! A "Check Own" button (I don't want to search the
class library .c files while searching for MY_OWN_DEFINE...)

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

+++++++++++++++++++++++++++

From: [e-mail] (Dale Semchishen)
Date: 31 May 92 01:03:35 GMT
Organization: MIND LINK! - British Columbia, Canada

I only have one wish for Think C, and its a big one.

The ability for the debugger to interpret 'C' code as it
single steps.  The benfits of this would be detection
of some runtime error such as;
        - indexing beyond the end of an array
        - attempting to use unitialized variables
        - attempting to deallocate memory that
          has not been allocated

I have used an X-windows 'C' development system that had
this ability.  You had to specify which source files
were compiled and which were interpreted.

- --
Dale Semchishen              | Internet: [e-mail]
Personal Designs Inc.        | tel: [phone]
                             | Vancouver, BC, Canada

+++++++++++++++++++++++++++

From: [e-mail] (Mark P. Richards)
Organization: University of Waterloo
Date: Tue, 2 Jun 1992 00:53:29 GMT

How about each source file remembering where it was on the screen (it
already remembers the tab stop setting and the font), and each project
remembering which source files were last open ?

Or is this part of v5 "already" ?

mark

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Organization: Digital Technology, International
Date: Tue, 2 Jun 92 01:02:55 GMT


I'd like to be able to use another editor.  I use MPW's shell
at work (I use MPW at work), and bought it to use at home, but
I found that "Use Disk" or whatever the option was in older
versions of ThinkC, is no longer there, so it's not convenient
to use MPW shell as my environment.  I'd like to be able to
send AppleEvents to ThinkC to tell it to compile/debug and work
with an MPW shell/ThinkC Debugger combination, sort of using
ThinkC as a compilation server.
- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Tue, 2 Jun 1992 02:14:20 GMT

In article <[e-mail]> [e-mail] (Thomas R. Kimpton) writes:

>I found that "Use Disk" or whatever the option was in older
>versions of ThinkC, is no longer there, so it's not convenient

Huh? What? Excuse me?

Use Disk is, and always has been, in the "Make..." dialog, which is under
the "Source" menu.


- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Dent)
Organization: DIALix Services, Perth, Western Australia
Date: Thu, 04 Jun 92 16:52:54 GMT

In <[e-mail]> [e-mail] (Mark P. Richards) writes:

>How about each source file remembering where it was on the screen (it
>already remembers the tab stop setting and the font), and each project
>remembering which source files were last open ?

Try CMaster from Jersey Scientific ([e-mail] or phone
[phone]).

It offers this plus
prototype generation
popup function menu
key bindings for many common actions
auto kissing of matching braces (with beep if no match) as you type
'vers' resource editing
and much more...
at a VERY reasonable price (I think it was $80 international, cheaper USA)

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241


---------------------------

From: [e-mail] (Brian Moore)
Subject: ETO 7 and MacApp
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Date: Fri, 5 Jun 1992 18:39:59 GMT

I just received ETO #7 and decided to attempt to learn how to use MacApp.
Reading through the manuals I noticed references to a manual called
"MacApp Class and Method Reference".  Looking through my manuals, I notice
'Hmm, it's not here.  Wonder where it when off to."  Looking through another
manual, I find that the manual is actually online, so I start searching
through the CD-ROM.  I search and search, but to no avail.  I call up
APDA and they also say that it should be online.  Now, since this manual
has "a complete description of every class provided in the MacApp class
library" I think it might be useful to actually know where it is.  Now I ask,
does anybody know where the silly thing is??

Thanks,
Brian Moore
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 5 Jun 92 20:57:36 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Brian Moore) writes:

>I just received ETO #7 and decided to attempt to learn how to use MacApp.
>Reading through the manuals I noticed references to a manual called
>"MacApp Class and Method Reference".  Looking through my manuals, I notice

I beleive it's gone away, replaced by 411 help files instead. You can't just
browse through 411 files (well, you can, but...); you access them from within
MacBrowse (a very usefull tool for figuring out MacApp) or MPW. The C&M Ref
was a Hyper{trash,card} stack and not very usefull - it's "complete"
descriptions or the classes and their functions were always 3 sentences or
less. No loss.
Best way to learn MacApp is to go through example code (the tutorial, etc).
MA 3 is more complex than 2 and thus hasn't quite supplanted it for general
use; it's easier to start with 2 (until you need to write complex dialogs,
then switch to 3).
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett - personal {opinions,ramblings,hallucinations}
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett - personal {opinions,ramblings,hallucinations}

---------------------------

End of C.S.M.P. Digest
**********************